Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

@bagowix uhmm... Integration with fastmcp already existed, but the author apparently forgot to add it to the documentation. Check this: https://github.com/vfaddey/fastmcp-dishka

@C3EQUALZz
Thanks for pointing this out! Yes, I’m aware of fastmcp-dishka, and I explicitly credit it as prior art in the project README:

https://github.com/bagowix/dishka-fastmcp#vs-fastmcp-dishka

This project is not intended to claim that it is the first or only FastMCP integration. It is an independent implementation with different lifecycle guarantees:

• REQUEST scopes are opened and finalized inside the injected handler, which keeps sync dependency creation, usage, and cleanup in the same FastMCP worker thread;
• it uses its own ContextVars and public FastMCP middleware hooks rather than private request-state attributes;
• SESSION scope is deliberately not exposed because FastMCP currently has no deterministic session teardown hook.

@bagowix for me personally it looks like "almost the same" library as exidting one. Did you contact an author of fastmcp-dishka to collaborate?

Regarding the implementation: I insist on avoiding ContextVars as it potentially leads to leaking resources a

@Tishka17 Thanks. No, I did not contact the author of fastmcp-dishka.

I looked through that project, but although both libraries solve the same problem, their lifecycle models are different. I want to keep this implementation independent and maintain it myself rather than try to rework the other project around a different approach.

I agree with your concern about ContextVars. My previous comment is outdated: I reworked the implementation before releasing v2.0.0.

The current version:

• does not use its own ContextVars or a Dishka middleware;
• resolves the container through FastMCP's public get_server() and get_context() APIs;
• opens and closes Scope.REQUEST inside the handler, so sync dependencies are created and finalized in the same worker thread.

The release is available on GitHub and PyPI.